Lab 3 - System Configuration

This lesson examines some broad configuration topics. Further detail on configuring specific services and options are contained in other units. To ensure each student’s screenshots are coming from their lab VM, begin by changing your system’s hostname from pc12345678 to pcNNNNNNNNN where NNNNNNNNN is your student number. Your screenshots will then show the hostname in the shell prompts so I can verify your work was done on your machine. Submissions which do not have your student number in your hostname showing in the shell prompts will not be marked.

Changing Hostname in Ubuntu

you can change the hostname using the following command:

# Replace NNNNNNNN with your StudentID
hostnamectl set-hostname pcNNNNNNNN
# Replace NNNNNNNN with your StudentID
hostnamectl set-hostname pcNNNNNNNN

Then verify that the hostname is set correctly and consistently:

hostnamectl
hostname
cat /etc/hostname
# The following file may need to be edited manually:
cat /etc/hosts
hostnamectl
hostname
cat /etc/hostname
# The following file may need to be edited manually:
cat /etc/hosts

Unattended Upgrades

The unattended-upgrades service uses a configuration file that contains runtime settings and rules. If you change the configuration, you need to restart the service. How much and whether to use the service is a topic for debate on servers, but it should be run on desktops at a minimum.

  1. Install and enable the unattended-upgrades package if you need to. Also, install the mailutils package if necessary to allow for local email progress reporting.

    sudo apt install unattended-upgrades mailutils
    sudo dpkg-reconfigure unattended-upgrades 
    sudo apt install unattended-upgrades mailutils
    sudo dpkg-reconfigure unattended-upgrades 
  2. Modify the configuration of the unattended-upgrades package to send emails when doing upgrades. Look for email-related settings. They are about halfway through the config file. Send an email to the local student user account whenever there are changes made by the upgrade service. Restart the service after you make changes so they take effect.

    sudo vi /etc/apt/apt.conf.d/50unattended-upgrades
    sudo systemctl restart unattended-upgrades 
    sudo vi /etc/apt/apt.conf.d/50unattended-upgrades
    sudo systemctl restart unattended-upgrades 
  3. Review the contents of the unattended-upgrades log files to see what gets logged there.

    sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades.log
    sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
    sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades.log
    sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

    Tip: To verify your configuration and troubleshoot unattended-upgrades, you can manually trigger the utility in debug mode (using -d switch): sudo unattended-upgrade -d. You should receive the email immediately.

Check the Grading section for the required screenshots.

Identifying Running Services to determine if they should be removed

There are multiple ways to determine which services are running, but the decisions about which ones need to be running are based on the system’s intended functions and any organizational policies that may apply.

  1. Identify services which are managed by systemd

    systemctl -t service 
    systemctl -t service 
  2. For every service listed that is unfamiliar, you might need to use systemctl, apt-cache, and dpkg to get information about that service. You may find that the service name is a package name. You may have to find which package installed the daemon programs a service has running. You may need to do some research online to learn enough about an unfamiliar package to know if it needs to be on your system.

  3. Check which ports are listening for connection or have outbound connections established. netstat or ss are good tools for this.

    sudo netstat -tulpn
    sudo netstat -tupn 
    sudo netstat -tulpn
    sudo netstat -tupn 
  4. If there are listening ports or outbound connections that you are not expecting based on the services you expect to be running, you could start investigating based on the process that has the port or connection open.

  5. Whether you identify a process of interest through a service investigation or a connection investigation, the simple process name may not be very helpful in identifying the service it came from.

    • Either type of investigation will give a process ID (PID). You can use ps -c PID to get more info on a running process.
    • You can use dpkg to find out if a process came from a package. If it did, you can use debsums to verify that the program file itself is legitimate and not a rogue.
    • If it is legitimate, then you can use the normal decision process for where you should have that software installed and running.
  6. Perform this activity for the service listening on port tcp/25.

    sudo netstat -tlpn
    sudo ss -tlpn
    ps -c <PID-of-process-listening-on-port-tcp-port-25>
    dpkg -S <pathname-of-process-command>
    debsums <process-command-package> | grep <pathname-of-process-command> 
    sudo netstat -tlpn
    sudo ss -tlpn
    ps -c <PID-of-process-listening-on-port-tcp-port-25>
    dpkg -S <pathname-of-process-command>
    debsums <process-command-package> | grep <pathname-of-process-command> 
  7. Run systemd-analyze security in both summary mode, and specifically for a service to see what it gives you.

    systemd-analyze security
    systemd-analyze security hddtemp
    systemd-analyze security
    systemd-analyze security hddtemp

Please refer to the Grading section. You will be using the above tools to investigate one service that is running.

User Accounts

Many times, user accounts exist which were automatically created, but are not needed. Unwatched accounts are a target for crackers. Accounts which own nothing in the filesystem, and have no running processes are usually either end-user accounts, application accounts, historical accounts, or reference accounts.

  1. Identify accounts on the system that have shell access
  2. Identify accounts on the system that own no files
#!/bin/bash
 # this script display a list of users from the passwd file who own no files
for user in `cut -d : -f 1 /etc/passwd`; do
  find / -ignore_readdir_race -user $user -ls -quit | grep -q $user || echo $user
done
#!/bin/bash
 # this script display a list of users from the passwd file who own no files
for user in `cut -d : -f 1 /etc/passwd`; do
  find / -ignore_readdir_race -user $user -ls -quit | grep -q $user || echo $user
done
  1. Identify accounts that have no running processes
  2. Accounts which do not appear to have a legitimate reason to be on your system should be researched

Resource Limits

This example of setting resource limits sets limits on interactive system users. As such, it requires the limits to be set at login, and use the PAM library to do it.

  1. Review the commented example settings in /etc/security/limits.conf
  2. Add a limit of 2 logins for the student user
  3. Start multiple remote sessions in multiple terminal windows and verify you cannot log in more than twice on the student account simultaneously

Please refer to the Grading section for the required screenshot!

Lynis

Lynis is a tool which can be used for system examination but is also very useful for hardening activities. Along with identifying things that are not in a typical state, it can make many recommendations regarding insecure configurations. This can be helpful when you have a system running software you may not be familiar with. Follow the steps in this lab to install, update, and run Lynis. A current version of Lynis running properly and using it to fix at least one thing is part of the mark for this lab.

Refer to the Grading Section for required screenshots!

  1. Add the lynis community repo to your apt configuration.

  2. Run apt update and install lynis to ensure you have the latest version. If you already had lynis installed, do apt upgrade instead of install.

  3. Run lynis in system audit mode.

    sudo lynis audit system 
    sudo lynis audit system 
  4. How many suggestions did it give you? Review the warnings.

  5. Choose one issue from the list of issues it shows that is related to access security and modify your configuration to eliminate or mitigate the exposure.

  6. Re-run lynis and verify it no longer complains about the fixed issue.

Grading

Submit your results and screenshots as per instructions posted on Blackboard. Everywhere there is a screenshot marker in the instructions, you must capture enough to show the command you ran and the results of running it.

  1. Leave your VM running long enough to receive an email from unattended-upgrades. Include a screenshot of the email. You can use the mailx tool to read email for a screenshot.
  2. In the section on investigating running services, do the investigation for the service listening on port tcp/25. Use netstat and ss to find the process, ps to find the executable, dpkg to find the package, and debsums to validate that the executable is legitimate. Include screenshots showing this process on your system.
  3. Identify a list of the accounts on your system that do not own any files. Note that your system may be slightly different from another student’s in this lab, depending on what lab work each of you has done up to this point. Include screenshots showing how you found the accounts and provide a list of these accounts from your system.
  4. Include a screenshot showing what was displayed when you tried to exceed the 2 ssh login limit from remote host.
  5. Include one screenshot showing the version of lynis you have and a warning from lynis for a specific item you can fix, and one screenshot showing the subsequent output showing it is no longer a concern after you have fixed it.